Possible support for "embedded" SCA mode

[Dave Tonge]

There is currently a legislative requirement for some banks in the EU to allow TPPs to use an “embedded' mode where the TPP collects the user’s credentials and passes them through to the bank.

While this is not our recommended approach, maybe we should consider a way of supporting it. This would help with harmonisation efforts so that we can try and get FAPI adopted more widely.

This is how the Berlin Group support this type of interaction:

It is important to note that there is a requirement for the TPP to receive back a challenge to present to a user.

One idea for how to implement this would be to use CIBA as it already has the concept of an “authorization session” via the auth_req_id.

The flow could be:

• RP → AS: /bc-authorize Create authorization request with a parameter indicating that embedded auth is preferred
• AS → RP: Ask the user for username/password
• RP → AS /token {auth_req_id, auth_params: {user, password}}
• AS → RP: Ask the user for OTP
• RP → AS /token {auth_req_id, auth_params: {OTP}}
• AS → RP Token

No new endpoints would be needed. We would need extensions to the backchannel authentication endpoint and the token endpoint.

‌

‌

‌

[Anders Rundgren]

Note that EMV does not require a challenge from the TPP, it is created entirely locally in the payment terminal.

Yeah, here are 9 billions of EMV cards that currently cannot use Open Banking APIs.

[Joseph Heenan]

It’s an interesting idea.

A few thoughts:

1. Doing user authentication at the token endpoint seems conceptually to be a notable deviance from current CIBA/OIDC/OAuth, and that may outweigh the advantage of not creating a new endpoint
2. I wonder if it might be bit more flexible, both for vendors & banks deploying this, (and possibly resolve point 1) if we did something [not unlike some of the concepts in oauth.xyz/TxAuth] where the AS returns a “do this then call this url” type structure. But then that’s almost what your suggestion does but with the url always being the token endpoint. It’s also not dissimilar to the way CIBA expanded the token endpoint to return ‘not yet’ in the polling case.

‌

[Anders Rundgren]

@Joseph Heenan How does that translate to EMV authorizations?

[Joseph Heenan]

Anders: I don’t even understand how you see EMV cards calling APIs.

For clarity, my comment was a response to Dave’s initial suggestion.

‌

[Anders Rundgren]

@Joseph Heenan I imagine that @Dave Tonge 's posting was a direct reaction to my mail which also had you as recipient. The NextGenPSD2 folks want to support EMV cards by bundling EMV-signatures to payment requests. This will make their API compatible with Apple Pay as well as traditional EMV cards.

That’s (IMO…) way more interesting than targeting outdated solutions like “Sofort” (which probably was the origin for the Embedded SCA mode).

[Francis Pouatcha]

The first design decision to be taken here is the definition of a pre-authorization request (we can call prepare service request). the general open banking service flow will look like:

1. prepare service request : returns the authorization flow
2. authorize service request : returns the authorization token
3. confirm service request

‌

“prepare service request“ in NextGenPSD2 are payment-initiation-request, consent-initiation-request.

‌

This pre-authorization request shall be independent of the "AuthN/AuthZ Flow/Protocol". The final decision on whether to AuthZe this “service request“ is taken by the ASPSP. Recall that according to European PSD2 RTS, a service request might be exempted from SCA leading to. no authorization at all.

‌

In existing open banking implementations, the ASPSP is a composition of an AS and a RS in oAuth jargon (or OP and RP in OIDC language). As for now there is no clarity on wether the AS or the RS is the. destination of the service request. This is why we will use the ASPSP bellow to represent the ASPSP-AS and the ASPSP-RS.

‌

The decision on whether and how to authorize a service request looks like:

• TPP must collect specifics of the service request (transaction), like the consumption device, transaction details and add them to the service request.

• TPP shall declare his AuthZ capabilities and preferences [decoupled (CIBA) || redirect || oauth || embedded]

• If known, TPP must add an indication of the PSU identity to the AuthZ request (situational)

• Based on this details, based on ASPSP capabilities, based on ASPSP known PSU AuthZ capabilities (SCA App, risk profile)

ASPSP will select an AuthZ flow and instruct the TPP to proceed accordingly.

‌

A big design decision to be made is on how to proceed with preauthorization request (or prepare service request). These might also be very cumbersome and their processing might not be possible without interaction with the ASPSP-RS.

→ We can decide to direct this pre-authorization request to the ASPSP-AS, and let the ASPSP-AS collaborate with the ASPSP-RS to take the decision.

→ We can decide to address the pre-authorization request (a.k.a. prepare service request) to the ASPSP-RS and let the ASPSP-RS generate AuthZ requirements (see RAR, JAR, AuthZ-protocol) that will be used to inititate the AuthZ process with the ASPSP-AS.

‌

IMHO:

• CIBA "Authentication Request" is looking too protocol specific, to be used as a pre-authorization request. In particular the asynchronous design deeply rooted in the protocol.
• PAR - RAR/JAR also provide some hint on how to approach the embedded design in an oAuth environment. But still too limited as the mapping of the service-request to the RAR, JAR is left to the oAtuh Client (TPP).

I will take time this weekend and suggest a sequence of call that could be used as an entry point to address the embedded workflow.

[Francis Pouatcha]

This a sample sequence diagram showing all three auth flows for open banking (embedded, decoupled and redirect) including the role of ASPSP’s AS, Open Banking API (RS) and TPP. I also separated the RO view into consuming device and auth device.

‌

Here is the corresponding plantuml code, in case there is any modification to be done.

‌

@startuml

participant "PSU\nResource Owner\nConsuming Device" as RO
participant "PSU\nResource Owner\nAuth Device" as AuthD
participant "TPP\nClient\nRP" as Client
participant "ASPSP\nAuthorization Server\nOpenID Provider" as  AuthServer 
participant "ASPSP\nResource Server\nOpen Banking API" as RS

RO -> Client ++ : PSU initiates a payment via TPP
Client -> RS ++ : Payment-Initiation Request
note right of Client
    - JSON, PAIN.001,  MT940, ... (amount, payee, date)
    - Country specific data
    - AuthN-Constraints (id-token, acr, exp, ...)
end note
opt "Payer & Payer Account Known"
RS -> RS : validate Payment\ncheck availability of fund
RS -> RS : validate AuthZ\ncheck SCA exemption
end
return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
note right of Client
    AuthZ protocol decision taken by ASPSP-RS   
    - AuthN-Constraints: see above
    - AuthZ-Constraints:
      - PaymentId (a.k.a Transaction reference, TxRef)
      - Exemption if present, no further AuthZ.
      - Auth-Protocol (TxRef XOR Rich Authorization Request:RAR)
end note
Client -> AuthServer ++ : AuthZ-request(AuthN-Constraints, AuthZ-Constraints)
note right of Client
    - Protocol dependent AuthZ-request [CIBA, oAuth-PAR, ...]
    - AuthN constraints (acr, exp, ...)
end note
AuthServer  -> RS ++ : load RAR from Payment-Initiation Request (PaymentId)
return RAR
return AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
loop "while Challenge" "No initial challenge in case of exemption. Access token present."
    alt "EmbeddedChallenge"
        Client -> RO ++ : AuthN/AuthZ-Challenge 
        AuthServer  --> AuthD : inherent challenge message (dynamic linking, e.g. TAN)
        note right of AuthD
            A challenge inherent to payment might hae been
            sent to PSU auth device.
        end note
        return AuthZ-Grant
        Client ->  AuthServer  ++ : AuthZ-request(AuthZ-Grant)
        AuthServer  -> RS ++ : update Payment-Initiation-Request
        opt "Payer account known"
            RS -> RS : validate Payment
            RS -> RS : validate AuthZ
        end
        return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
        return AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
        deactivate Client
    else "DecoupledChallenge"
        AuthServer --> AuthServer ++ : Start back chanel auth
        AuthServer  -> AuthD ++ : push AuthN/AuthZ-Challenge 
        return AuthZ-Grant
        AuthServer  -> RS ++ : update Payment-Initiation-Request
        opt "Payer account known"
            RS -> RS : validate Payment
            RS -> RS : validate AuthZ
        end
        return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
        AuthServer  -> Client : AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
        deactivate  AuthServer 
        note right of Client
        could be psuh, poll, ping
        end note
    else "RedirectChallenge"x
        Client --> RO ++ : Redirect to  AuthServer  
        RO <->  AuthServer  ++ :  AuthN/AuthZ
        AuthServer  -> RS ++ : update Payment-Initiation-Request
        opt "Payer account known"
            RS -> RS : validate Payment
            RS -> RS : validate AuthZ
        end
        return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
        AuthServer  --> RO :  Redirect to Client (AuthZ-Grant)
        deactivate AuthServer
        RO -> Client ++ : AuthZ-Grant
        Client ->  AuthServer  ++ : AuthZ-request(AuthZ-Grant)
        return AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
        deactivate RO
    end
end
note right of Client
    All three protocol flows (Embedded, decoupled, redirect) are completet when the Client/TPP obtain
    an access token and there is no more Auth[N|Z]-Challenge. This access token will be used to confirm
    payment at the resource server.
end note
Client -> RS ++ : Payment-Confirmation Request [AccessToken]()
return Payment-Status
Client --> RO : Payment-Status
@enduml

‌

[Tom Jones]

i guess you guys should look at the solutions proposed in the US in the last century. Protocols like STT, SET and ANSI X9.59. They all became too complex for user adoption and so failed to be adopted. Sounds like y’all are headed down the same path, so i suspect you will have the same result.

To Anders point. I would say, if you want an electronic check, then just create an electronic check and use the existing ACH for payment.

[Francis Pouatcha]

Display all three authZ flow in a single diagram has the purpose of agreeing on a common terminology, a common language we can use to reduce misunderstanding. Payment/Banking has never been simple due to AML and other actions and reporting provisions from regulators. Trying to use existing protocols like OIDC to map these payment protocols requires a dialog like the one we would like to start here. We need a common language over all schemes/flows like CIBA, oAuth/Redirect, Embedded.

• Using common term will help narrow differences
• Having the same semantic behind calls will also simplify task of OPs and RPs in supporting all alternatives.

‌

[Anders Rundgren]

@Tom Jones @Francis Pouatcha A core problem is the “value proposition” for regulated payment services since TPPs are (AFAIK…):

• not permitted creating keys and authenticate users (delegation)
• unable using the (nowadays sandboxed) keys provided by the banks in their own apps

TPPs who want to be “creative” are thus stuck with Web applications and dubious authentication methods like SMS callbacks.

[Ralph Bragg]

Francis,

The model proposed here seems to be the same same as the “lodging intent pattern” already used by the OBIE? Lodge a payment request, perhaps using an id_token to identify the requesting party. Bank responds with either. OK Done or No I want authorization please initiate X flow. If one of the options was a that a customer has a means of signing an embedded document then please just resubmit the pain message with a signature from the customer to bind this transaction?

I must still be missing something so my apologies. Next call can we discuss?

‌

‌

[Francis Pouatcha]

Hello Ralph,

All correct. The intention of the diagram above is to achieve such common understanding. Embedded in the context of the diagram above means the AuthN and AuthZ process in embedded in the user interface provided by the TPP. Means no redirection.

Many types of embedded AuthZ:

• Sending a PSU signed payment request (what you mention above)
• Enter banking password (PIN’s) and TAN’s in the TPP user interface. (Recall EBA’s RTS introduced a mandatory second factor for login to prevent misuse of PSU permanent password/PIN).
• …

The addition to current FAPI will be the generic Challenge/Response process with the TPP transporting PSU auth credentials to the ASPSP’s AS.

[Dave Tonge]

I propose we close this.

I will reach out to the Berlin Group to see what is happening and if there is a need we can re-open

[Anders Rundgren]

I have just been at a two-day Berlin Group conference. They are putting even more weight behind this kind of solution which for mere mortals = wallet.